-- *******************************************************************
-- CISCO-LWAPP-TC-MIB.my: Cisco LWAPP MIBs Textual Conventions
-- March 2006, Prasanna Viswakumar
--
-- Copyright (c) 2006,2007 by Cisco Systems, Inc.
-- All rights reserved.
-- *******************************************************************CISCO-LWAPP-TC-MIB DEFINITIONS::=BEGINIMPORTSMODULE-IDENTITY,Unsigned32,Gauge32FROM SNMPv2-SMI
TEXTUAL-CONVENTIONFROM SNMPv2-TC
ciscoMgmt
FROM CISCO-SMI;-- ********************************************************************
-- * MODULE IDENTITY
-- ********************************************************************ciscoLwappTextualConventions MODULE-IDENTITY
LAST-UPDATED"200702050000Z"ORGANIZATION"Cisco Systems, Inc."CONTACT-INFO"Cisco Systems,
Customer Service
Postal: 170 West Tasman Drive
San Jose, CA 95134
USA
Tel: +1 800 553-NETS
Email: cs-wnbu-snmp@cisco.com"DESCRIPTION"This module defines textual conventions used
throughout the Cisco enterprise MIBs
designed for implementation on Central
Controllers that terminate the Light Weight
Access Point Protocol from LWAPP Access
Points.
The relationship between CC and the LWAPP APs
can be depicted as follows:
+......+ +......+ +......+ +......+
+ + + + + + + +
+ CC + + CC + + CC + + CC +
+ + + + + + + +
+......+ +......+ +......+ +......+
.. . . .
.. . . .
. . . . .
. . . . .
. . . . .
. . . . .
+......+ +......+ +......+ +......+ +......+
+ + + + + + + + + +
+ AP + + AP + + AP + + AP + + AP +
+ + + + + + + + + +
+......+ +......+ +......+ +......+ +......+
. . . .
. . . . .
. . . . .
. . . . .
. . . . .
+......+ +......+ +......+ +......+ +......+
+ + + + + + + + + +
+ MN + + MN + + MN + + MN + + MN +
+ + + + + + + + + +
+......+ +......+ +......+ +......+ +......+
The LWAPP tunnel exists between the controller and
the APs. The MNs communicate with the APs through
the protocol defined by the 802.11 standard.
LWAPP APs, upon bootup, discover and join one of the
controllers and the controller pushes the configuration,
that includes the WLAN parameters, to the LWAPP APs.
The APs then encapsulate all the 802.11 frames from
wireless clients inside LWAPP frames and forward
the LWAPP frames to the controller.
GLOSSARY
Access Point ( AP )
An entity that contains an 802.11 medium access
control ( MAC ) and physical layer ( PHY ) interface
and provides access to the distribution services via
the wireless medium for associated clients.
LWAPP APs encapsulate all the 802.11 frames in
LWAPP frames and sends it to the controller to which
it is logically connected.
Advanced Encryption Standard ( AES )
In cryptography, the Advanced Encryption Standard
(AES), also known as Rijndael, is a block cipher
adopted as an encryption standard by the US
government. It is expected to be used worldwide
and analysed extensively, as was the case with its
predecessor, the Data Encryption Standard (DES).
AES was adopted by National Institute of Standards
and Technology (NIST) as US FIPS PUB 197 in
November 2001 after a 5-year standardisation
process.
Central Controller ( CC )
The central entity that terminates the LWAPP protocol
tunnel from the LWAPP APs. Throughout this MIB,
this entity is also referred to as 'controller'.
Light Weight Access Point Protocol ( LWAPP )
This is a generic protocol that defines the
communication between the Access Points and the
Central Controller.
Management Frame Protection ( MFP )
A proprietary mechanism devised to integrity protect
the otherwise unprotected management frames of the
802.11 protocol specification.
Message Integrity Check ( MIC )
A checksum computed on a sequence of bytes and made
known to the receiving party in a data communication,
to let the receiving party make sure the bytes
received were not compromised enroute.
Mobile Node ( MN )
A roaming 802.11 wireless device in a wireless
network associated with an access point.
Temporal Key Integrity Protocol ( TKIP )
A security protocol defined to enhance the limitations
of WEP. Message Integrity Check and per-packet keying
on all WEP-encrypted frames are two significant
enhancements provided by TKIP to WEP.
Wired Equivalent Privacy ( WEP )
A security method defined by 802.11. WEP uses a
symmetric key stream cipher called RC4 to encrypt the
data packets.
802.11n
802.11n builds upon previous 802.11 standards by
adding MIMO (multiple-input multiple-output). MIMO
uses multiple transmitter and receiver antennas to
allow for increased data throughput through spatial
multiplexing and increased range.
Control/Extension Channel
A single 802.11 channel is 20 MHz wide. 802.11n allows
the use of channels of width 40 MHz by combining two
20 MHz channels. The channels are known as the primary
or control channel and secondary or extension channel.
Both the channels are used for transmission
and reception of data.
REFERENCE
[1] Part 11 Wireless LAN Medium Access Control ( MAC )
and Physical Layer ( PHY ) Specifications.
[2] Draft-obara-capwap-lwapp-00.txt, IETF Light
Weight Access Point Protocol.
[3] Enhanced Wireless Consortium MAC Specification,
v1.24.
[4] Enhanced Wireless Consortium PHY Specification,
v1.27."REVISION"200702050000Z"DESCRIPTION"Added new textual conventions CLDot11ChannelBandwidth,
CLDot11Band and CLApAssocFailureReason."REVISION"200610310000Z"DESCRIPTION
"Added new textual conventions CLMfpEventSource,
CLCdpAdvtVersionType and CLDot11ClientStatus."REVISION"200604130000Z"DESCRIPTION"Initial version of this MIB module."::={ ciscoMgmt 514}-- ********************************************************************
-- TEXTUAL CONVENTION
-- ********************************************************************CLApIfType ::=TEXTUAL-CONVENTIONSTATUScurrentDESCRIPTION"This textual convention defines the type of a
wireless interface.
The semantics are as follows:
dot11bg - This value indicates that the radio
interface follows 802.11b or 802.11g standard.
dot11a - This value indicates that the radio
interface follows 802.11a standard.
uwb - This value indicates that this is a Ultra
Wideband Interface."SYNTAXINTEGER{dot11bg(1),dot11a(2),uwb(3)}CLDot11Channel ::=TEXTUAL-CONVENTIONSTATUScurrentDESCRIPTION
"This textual convention defines the possible channel
numbers in an 802.11 communication channel. The
802.11 radio interface of an Access Point operates
in one of the possible channels at any point of time
for wireless data communication with 802.11 based
wireless clients."SYNTAXUnsigned32(1..14 | 34 | 36 | 38 | 40 | 42 | 44 | 46 | 48 | 52 | 56 | 60 | 64 | 149 | 153 | 157 | 161)
CLDot11ClientStatus ::=TEXTUAL-CONVENTIONSTATUScurrentDESCRIPTION"This textual convention defines the states
of an 802.11 client.
The semantics are as follows:
idle(1) - client is in idle mode.
aaaPending(2) - client's authentication is pending.
Request has been sent to AAA server for authentication.
authenticated(3) - client has been authenticated.
associated(4) - client is associated, but not
authenticated.
powersave(5) - client is in powersave mode.
disassociated(6) - client has dissociated and not in
any of the 802.11 networks managed by the controller.
tobedeleted(7) - client is marked for deletion.
probing(8) - state before association. The client
will be removed if it does not associate.
excluded(9) - client has been marked as excluded after fixed
number of authentication failures."SYNTAXINTEGER{idle(1),aaaPending(2),authenticated(3),associated(4),powersave(5),disassociated(6),
tobedeleted(7),probing(8),excluded(9)}CLEventFrames ::=TEXTUAL-CONVENTIONSTATUScurrentDESCRIPTION"This textual convention defines the possible
802.11 management frame subtypes.
cLAssocRequestFrm - 802.11 Association Request
frame
cLAssocResponseFrm - 802.11 Association Response
frame
cLReAssocRequestFrm - 802.11 Reassociation
Request frame
cLReAssocResponseFrm - 802.11 Reassociation
Response frame
cLProbeRequestFrm - 802.11 Probe Request frame
cLProbeResponseFrm - 802.11 Probe Response
frame
cLReserved1 - Reserved for future use
cLReserved2 - Reserved for future use
cLBeaconFrm - 802.11 Beacon frame
cLAtimFrm - 802.11 Adhoc Traffic Indication
Map frame
cLDissociationFrm - 802.11 Dissociation
frame
cLAuthenticationFrm - 802.11 Authentication
frame
cLDeAuthenticationFrm - 802.11 Deauthentication
frame"REFERENCE"Part 11 Wireless LAN Medium Access Control ( MAC )
and Physical Layer ( PHY ) Specifications,
Section 7.1.3.1.2 - Type and Subtype fields"SYNTAXBITS{cLAssocRequestFrm(0),
cLAssocResponseFrm(1),cLReAssocRequestFrm(2),cLReAssocResponseFrm(3),cLProbeRequestFrm(4),cLProbeResponseFrm(5),cLReserved1(6),cLReserved2(7),cLBeaconFrm(8),
cLAtimFrm(9),cLDissociationFrm(10),cLAuthenticationFrm(11),cLDeAuthenticationFrm(12)}CLMfpEventType ::=TEXTUAL-CONVENTIONSTATUScurrentDESCRIPTION"The type of the MFP anomaly event.
invalidMic - The MFP Validation has identified
that the MIC carried by a particular management
frame is invalid.
invalidSeq - The MFP validation has identified
that a particular management frame is carrying an
invalid sequence number. Note that an invalid
sequence number error can also be detected due to an
incorrect timestamp in the MFP information element.
The incorrect timestamp could possibly be due to the
fact that the detecting AP's time window is not in
synchronization with that of other APs in the
MFP framework.
noMic - The MFP validation has detected a management
frame without the MFP information element.
unexpectedMic - The MFP validation has detected a
management frame as carrying a MIC value when
protection is not enabled on the WLAN.
ccmpDecryptError - An MFP frame that was apparently
received from a client in an AES-CCMP encrypted
session was rejected by the Access Point because it
could not be decrypted.
ccmpInvalidMhdrIe - An MFP frame that was apparently
received from a client in an AES-CCMP encrypted
session was rejected by the Access Point because it
contained an invalid MHDR information element, or the
MHDR information element was not present.
ccmpInvalidReplayCtr - An MFP frame that was apparently
received from a client in an AES-CCMP encrypted session
was rejected by the Access Point because the replay
counter was not valid.
tkipInvalidIcv - An MFP frame that was apparently
received from a client in a TKIP encrypted session was
rejected by the Access Point because it contained an
invalid Integrity Check Value.
tkipInvalidMic - An MFP frame that was apparently
received from a client in a TKIP encrypted session was
rejected by the Access Point because the message
integrity check failed.
tkipInvalidMhdrIe - An MFP frame that was apparently
received from a client in a TKIP encrypted session was
rejected by the Access Point because it contained an
invalid MHDR information element, or the MHDR
information element was not present.
tkipInvalidReplayCtr - An MFP frame that was apparently
received from a client in a TKIP encrypted session was
rejected by the Access Point because it the replay
counter was not valid.
bcastDisassociationFrameRcvd - The Access Point detected
a broadcast disassociation frame. Broadcast
disassociation frames are rejected by CCXv5 compliant
devices.
bcastDeauthenticationFrameRcvd - The Access Point
detected a broadcast deauthentication frame. Broadcast
deauthentication frames are rejected by CCXv5 compliant
devices.
bcastActionFrameRcvd - The Access Point detected a
broadcast action frame. Broadcast action frames are
rejected by CCXv5 compliant devices."SYNTAXINTEGER{invalidMic(1),invalidSeq(2),noMic(3),unexpectedMic(4),ccmpNoEncryptError(16),ccmpDecryptError(17),
ccmpInvalidReplayCtr(19),tkipNoEncryptError(20),tkipInvalidIcv(21),tkipInvalidMic(22),tkipInvalidMhdrIe(23),tkipInvalidReplayCtr(24),bcastDisassociationFrameRcvd(32),bcastDeauthenticationFrameRcvd(33),
bcastActionFrameRcvd(34)}CLMfpEventSource ::=TEXTUAL-CONVENTIONSTATUScurrentDESCRIPTION"The source of the MFP anomaly event.
infrastructureMfp - The source of the MFP event is
an infrastructure device that implements MFP.
clientMfp - The source of the MFP event is a client
device that implements MFP."SYNTAXINTEGER{infrastructureMfp(1),
clientMfp(2)}CLMfpVersion ::=TEXTUAL-CONVENTIONSTATUScurrentDESCRIPTION"This textual convention lists the versions of
the MFP protocol."SYNTAXINTEGER{mfpv1(1),mfpv2(2)}CLTimeBaseStatus ::=TEXTUAL-CONVENTION
STATUScurrentDESCRIPTION"This textual convention is used to define the
time synchronization of entities with their
respective time bases.
cTimeBaseInSync - This value indicates that the
respective entity is in synchronization with
its time base.
cTimeBaseNotInSync - This value indicates that
the respective entity is not in synchronization
with its time base."SYNTAXINTEGER{cTimeBaseInSync(1),cTimeBaseNotInSync(2)}CLSecEncryptType ::=TEXTUAL-CONVENTION
STATUScurrentDESCRIPTION"This textual convention defines the type of
encryption to be applied to a WLAN.
The semantics are as follows:
tkip - This value indicates that TKIP encryption
is configured for data protection.
aes - This value indicates that AES encryption
is configured for data protection."SYNTAXBITS{tkip(0),aes(1)}CLSecKeyFormat ::=TEXTUAL-CONVENTION
STATUScurrentDESCRIPTION"This textual convention defines the type of
the key configured for encryption."SYNTAXINTEGER{default(1),hex(2),ascii(3)}CLDot11RfParamMode ::=TEXTUAL-CONVENTIONSTATUScurrentDESCRIPTION
"This textual convention defines how the RF
parameters used to manage roaming are chosen
by the controller.
default - controller reverts back to the default
values specified for the RF parameters.
auto - controller determines the RF parameters
automatically without any input from the end user.
custom - controller uses the RF parameters
configured by the end user. User is allowed to
configure the parameters only if the mode is set
to 'custom'."SYNTAXINTEGER{default(1),custom(2),auto(3)
}CLTsmDot11CurrentPackets ::=TEXTUAL-CONVENTIONSTATUScurrentDESCRIPTION"The number of packets received over a specified
period of time."SYNTAXGauge32CLCdpAdvtVersionType ::=TEXTUAL-CONVENTIONSTATUScurrentDESCRIPTION"This textual convention lists the versions of
the CDP protocol in use in LWAPP APs and Controllers."SYNTAXINTEGER{cdpv1(1),
cdpv2(2)}CLDot11ChannelBandwidth ::=TEXTUAL-CONVENTIONSTATUScurrentDESCRIPTION"This textual convention defines the channel
bandwidth for 802.11n radio interfaces.
The semantics are as follows:
five - This value indicates that the bandwidth
is 5 MHz.
ten - This value indicates that the bandwidth
is 10 MHz.
twenty - This value indicates that the bandwidth
is 20 MHz.
aboveforty - This value indicates that the bandwidth
is 40 MHz with the extension channel above the control
channel.
belowforty - This value indicates that the bandwidth
is 40 MHz with the extension channel below the control
channel."SYNTAXINTEGER{five(1),ten(2),twenty(3),aboveforty(4),belowforty(5)}CLDot11Band ::=TEXTUAL-CONVENTION
STATUScurrentDESCRIPTION"This textual convention defines the 802.11 frequency
band.
The semantics are as follows:
band2dot4 - This value indicates that the
2.4 GHz band is in use.
band5 - This value indicates that the
5 GHz band is in use."SYNTAXINTEGER{band2dot4(1),band5(2)}CLApAssocFailureReason ::=TEXTUAL-CONVENTIONSTATUScurrent
DESCRIPTION"This textual convention defines the possible reasons
for an AP's failure to get associated to a controller.
The semantics are as follows:
unknown - The reason for the AP not being able to
associate is unknown.
notSupported - The AP is not supported for management
by the controller."SYNTAXINTEGER{unknown(1),notSupported(2)}END